Created self-cleaning events & reactTo() for easy & reliable event clean-up.

reactTo() creates an object for your reaction function...
	... so you usually don't need to store or re-use reaction objects.
	But they can still be handy for storing arbitrary variables.
	Also good for  evt.target  checks.

Don't modify data directly, insetad use a set of functions to read, write, & modify the data.
	If you do this, your code will be able to edit various forms of data without being re-written.
	(simply swap out the functions that read/write the data)

An event's evt.target parameter should be used to prevent reacting to yourself.

React to changes in data instead of components.
	myReactions.reactTo( data.chipsets ).change = function(){}
	"data" is a collection of event emitters.
After data is modified, tell "data" collection to send a "change" event.
	data.changed( {target:myReactions );
	"data" then emits a "change" event
	Also set evt.arget to your reaction object so it won't react to its own change.

Components should not get & set their properties by their variable name.
	(this name shoud be easy to change for external code)

Create all components/MovieClips & references to them,  before programming or populating the components/MovieClips.

Place a wrapper movieClip within a scrollPane's content,
	then use scrollRect on this wrapper to efficiently crop everything you put inside of it...
	... This way, those things don't need to be individually cropped.
my_pane
	content
		myWrapper_mc
			backgrond_mc
			map_mc
			grid.mc

To detect onRollOver and onRollOut for clips within scroll-panes, use its "content"
	my_pane.content.onRollOver = function(){}

A scroll-pane's margin is 2 pixels around each side,
	This means its size needs to be +4
	A scroll pane's scroll bars take up 16 pixels, therefore...
	margin + scroll = 20 pixels
		320 x 240 => 340 x 260

It's easier to create a component, wait for onLoad(), and then populate it...
	... than it is to init it while creating it, and trying to detect it's draw() events.
	This is also a good idea because you'll use the same functions...
	...  during init that you'd use later on.
	(smaller interface = easier to remember)

Function hoisting does NOT work if it's inside of an "if" statement block...
... which actually makes sense if you think about it.
Redundant {} might also interfere with it.
Function hoisting only works when it's directly inside of any function block.

Errors should be objects which include a "type", so that external code can treat failures and aborting differently.

